التوكنز - التحدي الهندسي القادم لفرق الذكاء الاصطناعي

تخيل أن تفتح تقرير الميزانية السنوي لقسم الهندسة والتقنية في شركتك مع بداية شهر مايو، لتكتشف أن ميزانية الذكاء الاصطناعي المرصودة لعام ٢٠٢٦ بأكمله قد تبخرت تماماً في ١٢٠ يوماً فقط!

هذا السيناريو الكابوسي ليس افتراضياً؛ بل هو ما حدث حرفياً لشركة أوبر (Uber) في أبريل ٢٠٢٦. لم يكن السبب اختراقاً أمنياً أو مشروعاً عملاقاً فاشلاً، بل لوحة قيادة داخلية (Leaderboard) أنشأتها الإدارة لترتيب الفرق بحسب "حجم استخدامها لأدوات الذكاء الاصطناعي"، فتحول الاستهلاك بين المطورين إلى سباق محموم لحرق الموارد.

وحين سُئل أندرو ماكدونالد، رئيس العمليات في أوبر، عن العائد الملموس لكل هذه الأموال، أجاب بصراحة صادمة: "تلك العلاقة غير موجودة بعد" (That link is not there yet)، مؤكداً أنه إن لم تستطع الشركة ربط هذا الاستهلاك بميزات تصل للعميل، فسيصعب تبرير هذه الفواتير الباهظة.

لكن، ما هو هذا الشيء الذي تتسابق الفرق على حرقه، وتدفع الشركات الملايين مقابله كل شهر؟

ما هي "التوكنز" (Tokens) بالضبط؟

قبل أن نغوص في أرقام الشركات، دعنا نبسط المفهوم بعيداً عن التعقيد الأكاديمي:

في عالم الذكاء الاصطناعي التوليدي ونماذج اللغة الكبيرة (LLMs)، النموذج لا يقرأ الكلمات كجمل كاملة كما نقرأها نحن، ولا يفهم كود البرمجة دفعة واحدة؛ بل يفكك أي نص أو كود إلى وحدات بناء أساسية وصغيرة تُسمى التوكنز (Tokens).

• التوكن الواحد يعادل تقريباً من ٣ إلى ٤ أحرف إنجليزية، أو نحو ثلاثة أرباع كلمة. وفي لغات البرمجة، قد يمثل التوكن كلمة مفتاحية، أو رمزاً مثل { أو }، أو مسافة بادئة (Indentation).

• التوكن هو العملة الحقيقية للذكاء الاصطناعي: أنت تدفع ثمن التوكنز مرتين في كل طلب؛ مرة عند إرسال الكود والسياق للنموذج (Input Tokens)، ومرة ثانية لكل سطر كود أو شرح يكتبه النموذج رداً عليك (Output Tokens).

• والأهم من ذلك: كلما طلبت من أداة المساعد البرمجي قراءة مستودع الكود بأكمله (Codebase)، أو تركت "الوكيل الذكي" (AI Agent) يعمل في حلقة تكرارية ليصحح خطأ برمجياً ذاتياً، فأنت تضخ مئات الآلاف وأحياناً ملايين التوكنز في ثوانٍ معدودة.

الرقم الذي يوضح أين يتجه العالم ذكره تقرير حديث لـ جولدمان ساكس (Goldman Sachs): استهلاك التوكنز عالمياً مرشح ليتضاعف ٢٤ مرة بحلول عام ٢٠٣٠.

الصدمة في أروقة الشركات الكبرى

ما حدث في أوبر فتح الباب على مصراعيه لاكتشاف أرقام لم تكن تخطر على بال أحد داخل أكبر قلاع التقنية:

• ميتا (Meta): كشفت بيانات داخلية أن مهندساً واحداً استهلك بمفرده ٢٨٠ مليار توكن خلال شهر واحد فقط! هذه الكمية تكلف وحدها نحو ١.٤ مليون دولار بأسعار نماذج مثل Claude Opus.

• قطاع السفر التقني: كشف تقرير تحليلي لمنصة SemiAnalysis عن شركة سفر عالمية تضم ٨٠٠ مهندس برمجيات، تستهلك سنوياً ما يقارب ١٠ ملايين دولار على التوكنز وأدوات الذكاء الاصطناعي فقط.

• مايكروسوفت (Microsoft): وزعت أداة Claude Code على آلاف المهندسين لتحسين الإنتاجية، لكنها في يونيو ٢٠٢٦ اتخذت قراراً استراتيجياً بإلغاء معظم التراخيص المباشرة وحوّلت فرقها إلى GitHub Copilot CLI الأداة الأرخص كلفة والمملوكة لها داخلياً للسيطرة على تكاليف الحوسبة المتصاعدة.

الشركات كانت تظن أنها تدفع اشتراكاً شهرياً ثابتاً، فاكتشفت فجأة أنها تتعامل مع فاتورة مفتوحة تزيد بأقصى سرعته مع كل محرر كود.

مفارقة جيفونز: لماذا تزداد الفاتورة كلما انخفض سعر التوكنز؟

هنا تظهر معضلة اقتصادية شهيرة تُعرف بـ "مفارقة جيفونز" (Jevons Paradox).

صاغ الاقتصادي ويليام ستانلي جيفونز هذه النظرية في القرن التاسع عشر عندما لاحظ أن زيادة كفاءة المحركات البخارية وتقليل استهلاكها للفحم لم يؤديا إلى تقليل استهلاك الفحم الإجمالي، بل حدث العكس تماماً: أصبحت الطاقة أرخص وأكثر كفاءة، فزادت تطبيقاتها وتضاعف الطلب الكلي على الفحم بصورة قياسية.

هذا يفسر واقع الذكاء الاصطناعي اليوم؛ أسعار التوكنز تنخفض كل بضعة أشهر وتصبح النماذج أسرع، لكن الفواتير داخل الشركات تتضاعف ١٠ أضعاف والسبب:

• المطور لم يعد يطلب إكمال سطر برمجي واحد؛ بل يطلب بناء ملفات كاملة وتوليد اختبارات آلية وقراءة وثائق المشروع كاملاً.

• انخفاض التكلفة شجع على إطلاق الوكلاء البرمجيين المستقلين (Agents) التي تدور في حلقات مستمرة (Loops) تستهلك ملايين التوكنز في دقائق دون تدخل بشري مباشر.

كيف تعاملت الشركات مع التوكنز؟

عندما تفاجئت الشركات من حجم الإنفاق، انقسمت أساليب الحوكمة والإدارة إلى مدارس متباينة:

• فخ السقف الصارم (Hard Cap) - شركة دفاع وطيران أمريكية: بحسب تقرير SemiAnalysis، قرر رئيس الذكاء الاصطناعي في إحدى كبرى شركات الدفاع فرض سقف مالي شهري صارم وثابت لكل مهندس لمنع التجاوز. النتيجة كانت كارثية: المهندسون الأكثر إنتاجية وشغفاً استنفدوا حصة الشهر كاملة خلال ٤ أيام فقط، وأصيبت مشاريعهم بالشلل لبقية الشهر هذا يشبه تماماً فريق أجايل يحرق كل الـ (Story Points) في أول يومين من السبرنت ثم يجلس عاطلاً حتى نهاية السبرنت.

• الحد المرن والمساءلة الإنسانية (Soft Limit) - شركة أمن سيبراني مدرجة: اعتمدت نهجاً أكثر ذكاءً؛ وضعت حداً مرناً بقيمة ٨٠٠ دولار شهرياً لكل مهندس جديد، ولكن عند تجاوز هذا الرقم لا تُقطع الخدمة آلياً، بل تفتح محادثة مباشرة مع المدير لمعرفة السياق وأسباب الاستهلاك. هذا النهج ينسجم تماماً مع ثقافة الـ Retrospective في أجايل: توجيه ومساءلة هدفها التعلم لا العقاب الأعمى.

• تغيير الإعدادات الافتراضية بمبدأ WSJF - شركة سفر تقنية عالمية: غيّرت الشركة الإعدادات الافتراضية في كل المحررات من نموذج Opus الأغلى والأعلى قدرة إلى نموذج Sonnet الأرخص، واشترطت أن يقوم المهندس باختيار النموذج الأغلى بنفسه عن وعي عندما تتطلب المهمة ذلك فعلاً. هذا تطبيق حرفي لمبدأ WSJF (Weighted Shortest Job First)؛ لا تستخدم المورد الأغلى إلا في المشكلة المعقدة ذات القيمة الأعلى، وتجنب استخدامه في المهام الروتينية.

حقيقة الأرقام من المصدر (بيانات Anthropic): تشير أرقام أنثروبيك إلى أن متوسط إنفاق المطور على أدوات مثل Claude Code يتراوح بين ١٥٠ و٢٥٠ دولاراً شهرياً، وأن ١٠% فقط من المطورين يتجاوزون ٣٠ دولاراً يومياً. هذا يعني أن المشكلة ليست أزمة عامة تستدعي منع التقنية، بل هي نمط استهلاك استثنائي لشريحة صغيرة يمكن رصدها وحوكمتها بحكمة.

هوس الاستهلاك (Tokenmaxxing) والسرعة الوهمية

في خضم الحماس للذكاء الاصطناعي، نشأت ثقافة غير واعية داخل الفرق البرمجية يمكن تسميتها بـ "هوس الاستهلاك" (Tokenmaxxing) وهو الميل إلى استخدام الذكاء الاصطناعي في كل شاردة وواردة لمجرد إظهار أننا نواكب التقنية.

يلخص جيه آر ستورمنت، المدير التنفيذي لمؤسسة FinOps، هذا التحول بقوله في تقرير SemiAnalysis:

"تغير الحديث كله من هوس الاستهلاك (Tokenmaxxing) وشعار 'انطلق بأقصى سرعة'، إلى 'نحتاج حواجز حماية، وكيف نتحكم بالتوكنز؟'"

في إدارة الأجايل، نعلم أن زيادة الحركة لا تعني بالضرورة زيادة التقدم؛ وهذا ما أثبتته الدراسات الميدانية بالأرقام:

• دراسة Jellyfish: المهندسون الأكثر استهلاكاً للتوكنز أنتجوا ضعف الكود تقريباً، لكنهم استهلكوا ١٠ أضعاف كمية التوكنز.

• دراسة Faros AI (على ٢٠ ألف مطور): حجم الكود المكتوب ارتفع بوضوح، لكن بالتوازي قفزت معدلات الأخطاء وإعادة كتابة الكود (Code Rewrites).

وهذا ما نسميه في هندسة البرمجيات "السرعة الوهمية" (Phantom Velocity)؛ فريق يشعر بأنه سريع جداً لأنه يولد آلاف الأسطر في دقائق، بينما الحقيقة أنه يضخم الدَّين التقني (Technical Debt) وينقل عنق الزجاجة إلى مهندسي المراجعة وفحوصات الجودة.

كيفية التعامل الأمثل مع التوكنز

التوكنز ليست حلاً سحرياً يغني عن التفكير الهندسي، وليست مشكلة يجب تجنبها؛ بل هي مورد إنتاجي متقدم، تماماً كساعات عمل المطورين وسعة السيرفرات.

للخروج بأقصى قيمة من هذا المورد، نحتاج لثلاث قواعد مستعارة من أفضل ممارسات إدارة البرامج والأجايل:

١- التعامل مع الميزانية كسعة فريق (Team Capacity): كما نخطط لسعة السبرنت بناءً على وتيرة الإنجاز التاريخية وليس التمني، يجب أن تُبنى ميزانية التوكنز على بيانات استهلاك واقعية (كما تفعل أدوات Faros وJellyfish)، بعيداً عن التقديرات العشوائية.

٢- قياس الأثر (Outcome) بدلاً من الاستهلاك (Output): السؤال الذي يجب أن تسأله الإدارة ليس: "كم توكنز استهلك الفريق؟"، بل: "هل ساعدنا هذا الاستهلاك في إطلاق ميزات أسرع للمستخدم وتقليل زمن الإصلاح؟". قياس التوكنز دون ربطها بالقيمة يماثل قياس إنتاجية المبرمج بعدد أسطر الكود

٣- حواجز حماية متدرجة (Guardrails): الجمع بين النماذج الاقتصادية افتراضياً، وتحديد حدود مرنة تفتح حواراً هندسياً عند تجاوزها، تماماً مثل معايير الإنجاز (Definition of Done) التي ترشد الفريق وتضمن الجودة دون أن تقيد حركته.

الشركات الفائزة في سباق الذكاء الاصطناعي لن تكون التي أحرقت توكنز أكثر، بل التي أحسنت توجيه تلك التوكنز لبناء قيمة حقيقية، وحوّلت الإنفاق إلى بيانات تدعم القرار.